The role of the computer continues to expand from desktop to notebook to netbook to personal digital assistant (PDA) to cell phones and smart appliances. With the expanding role of the computer comes increasing demand for applications, such as device specific applications and web-based applications. Providing a pleasing User Experience (UX) for these applications continues to be a challenging task. Two major factors in this difficulty are the way UX designers work within the software development process and the difficulty of building modern applications whose quality level (lack of bugs) is high enough to ship. For instance, it can be difficult to focus on creating a pleasing UX when most of the resources go into fixing bugs.
Building applications today is a complex, expensive, and risky process, involving several phases, such as user/technology/market research, user experience (UX) design, architectural design, specification, programming, localization, testing, bug fixing, etc. A potentially problematic path (and perhaps the most complex phase) is the programming/testing/bug fixing path. The UX design is typically done relatively early in the process and removed from the working code. When the UX design is complete, it is transferred to the developers so they can “implement it” in the code. This means that although the UX design is created by the designer, it is then “owned” by the developer. There are several potential problems with this paradigm.
The first potential problem is that the UX design is subject to changes made by the developer. For instance, the developer may make changes in order to make the programming easier, to adjust the design to the programmer's opinion of what works best, and/or to define what happens in cases not anticipated by the UX designer. Second, as the design becomes real and tested by users, it usually requires adjustment. This adjustment is either done directly by the developer (since he now “owns” the design), or by the UX designer in a design environment that is isolated from the working code and then the adjustment is then transferred (and owned) by the developer.
Another potential problem is that as the individual features in the UX come together to make a whole application, it is potentially difficult to make UX adjustments across the whole application (based on problems discovered by real-code testing by users). The present concepts relate to unifying application building tools that address the above mentioned (and/or other) shortcomings of the existing paradigm.